Phase 2 of #1431. Wires the inline-class XML attributes from the
class-parse layer (commit 35ccc4f) through the generator so:

* `<class kotlin-inline-class="true" .../>` is emitted as a
  `readonly partial struct` wrapper around the underlying primitive
  (e.g. `J` -> `long`, `F` -> `float`) instead of a peer-class binding.
  The struct exposes `Value`, implicit conversions, equality, and
  ToString.

* `<parameter kotlin-inline-class-jni-type="L...;" .../>` makes the
  generator project the parameter's managed type to the wrapper struct
  while keeping JNI marshaling on the underlying primitive. Because the
  struct has implicit conversion operators, existing `JniArgumentValue`
  thunks compile unchanged.

* `<method kotlin-inline-class-return-jni-type="L...;" .../>` does the
  same for return values via `ReturnValue.managed_type`.

Plumbing:
* `ClassGen.IsKotlinInlineClass`, `ClassGen.KotlinInlineClassUnderlyingJniType`
* `Parameter.KotlinInlineClassJniType`
* `Method.KotlinInlineClassReturnJniType`
* `Parameter.Validate`/`ReturnValue.Validate` apply the projection by
  looking up the wrapper `ClassGen` via `SymbolTable`.
* New `KotlinInlineClassStruct` TypeWriter emits the wrapper struct.
* New `TypeNameUtilities.JniSignatureToJavaTypeName` helper.

Out of scope (acknowledged limitations): boxed/nullable/generic
inline-class positions still resolve to the (now-replaced) peer
binding; reference-backed inline classes; generic inline classes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

When the Kotlin compiler mangles a JVM method name for inline-class

binary compatibility (e.g. `tint(MyColor)` -> `tint-Rn_QMJI`), recover

the unmangled Kotlin source name and surface it in api.xml as the

`managedName` attribute. The mangled JVM name still appears in

`name`/`jni-signature` so JNI invocation targets the actual method.

With this and the Phase 2 inline-class -> struct projection, methods

that erase to colliding JVM signatures emit as plain C# overloads

distinguished by struct type, e.g.:

    void Tint (MyColor color);

    void Tint (MyAlpha alpha);

    void Tint (MyDp dp);

instead of the previous `Tint_Rn_QMJI` / `Tint_uzYZ1wI` mangled names.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

1. KotlinInlineClassStruct.cs: drop unused `using System;` and unused

   `klass` field; gate `object?`/`string?` annotations on

   `opt.NullableOperator` so consumers without nullable enabled don't

   get CS8632 warnings.

2. TypeNameUtilities.JniSignatureToJavaTypeName: also translate `\$`

   (JNI nested-type separator) to `.` so SymbolTable.Lookup() resolves

   nested inline classes.

3. KotlinFixups.DetectInlineClasses: only stamp underlying-JNI type

   when there is exactly one non-synthetic instance field AND that

   field is a JVM primitive descriptor (Z/B/C/D/F/I/J/S). Reference-

   backed inline classes (e.g. `value class Tag(val s: String)`) are

   skipped — the wrapper struct currently emits a primitive `Value`

   field, so they would otherwise produce wrong bindings.

4. KotlinFixups.GetInlineClassJniType: now also takes the JVM-erased

   descriptor of the position being projected (param/return/property)

   and only returns a JNI-type when it equals the inline class's

   underlying primitive. Boxed / nullable / generic inline-class

   positions (where the JVM signature stays `L...;`) are no longer

   incorrectly stamped — they fall through to the legacy peer-class

   binding path so JNI marshaling stays consistent. Applied at all

   four stamping sites: function param, function return, property

   getter return, property setter param.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>